Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Initial configuration

ProtectServer owner and identity certificates

search

ProtectServer owner and identity certificates

This section describes ProtectServer owner and identity certificates, how you can use them to establish an HSM as a certificate authority (CA) that authenticates other HSMs in your deployment, and how to establish trust relationships between HSMs in your deployment.

Overview

ProtectToolkit 7 allows you to generate an identity key and certificate on the HSM, ensuring that cryptographic objects can be replicated only to other ProtectServer 3 HSMs you control, and to secure messages between the HSM and PTK. The identity keys and certificates described below are unaffected by tamper events; they remain consistent unless explicitly replaced by the HSM Administrator. The procedures described here should be completed by the Administrator after installing a new ProtectServer 3 HSM.

The new identity scheme uses the following objects:

  • ProtectServer Owner Key (POK): ECC P-521 private key to identify the ProtectServer 3 HSM owner. This allows you to use a ProtectServer 3 HSM as a Certificate Authority (CA) to authenticate the other ProtectServer 3 HSMs in your organization.

  • ProtectServer Owner Certificate (POC): Self-signed ECC P-521 certificate that identifies the ProtectServer 3 HSM owner on other HSMs in your organization. When this certificate is created, it is held in a POC-Pending state until the POK is used to sign a PIK for the same HSM.

  • ProtectServer Identity Key (PIK): ECC P-521 private key to identify the ProtectServer 3 HSM. Required for Secure messaging and Token replication. When Authenticating ProtectServer 3 HSMs with an offline HSM CA, the PIK of the HSM being authenticated is held in a PIK-Pending state until the HSM's PIC is signed by the HSM CA.

  • ProtectServer Identity Certificate (PIC): ECC P-521 certificate that identifies the ProtectServer 3 HSM. Can be self-signed or signed by a POK. Required for Secure messaging and Token replication.

Trust between HSMs is established by the exchange of PICs, used for wrapping tokens and verifying signed information. An identity key pair is generated on the administrative token of each device. The PIC is either self-signed by the PIK, or by a higher POK created on one of your ProtectServer 3 HSMs. The POK allows you to use a ProtectServer 3 HSM as a Certificate Authority to verify the other HSMs in your organization.

Establishing a ProtectServer 3 HSM as the HSM certificate authority

You can use this procedure to create a POK/POC keypair on the ProtectServer 3 HSM that you plan to use as a Certificate Authority for the other ProtectServer 3 HSM in your organization. This HSM can be one that you use in production or keep separate from your production HSMs. This procedure is completed by the Administrator using the ctident tool.

Note

If you choose to use a POK/POC to authenticate HSMs for trust management, all HSMs that will trust each other must have their PIC signed by the same POK. Thales recommends using only one POK/POC, unless you wish to keep separate deployments of HSMs that explicitly cannot establish trust relationships between them.

A PTK client can hold only one POC at a time, so if you wish to maintain separate deployments, each deployment requires its own separate clients.

Prerequisites

  • The ProtectServer 3 HSM you wish to use as the HSM CA must be installed and available to your PTK client machine. You can authenticate any other ProtectServer 3 HSMs available to your PTK client as part of this procedure, or you can authenticate them later as they are added.

  • Ensure that you have initialized the ProtectServer Admin token on the certifying HSM CA and any others you wish to authenticate (see Initial configuration). You will need to provide the Admin PIN for each HSM being authenticated.

  • Ensure that you have synchronized the HSM clock(s) with the correct time on your PTK client (see Adjusting the HSM clock).

  • If you want to customize the location of the PTK client certificate store, edit the path in the ET_PTKC_GENERAL_CERT_STORE variable. For more information about editing the path in this variable, refer to General ProtectToolkit-C configuration items.

To establish a ProtectServer 3 HSM as the HSM certificate authority

  1. (Optional) List the ProtectServer 3 HSMs available to the PTK client.

    ctident list all

  2. Generate the POK/POC by specifying the desired certifying HSM by its device or serial number (sn:<serialnum>) as listed in the PTK client.

    ctident gen-owner <CA_devicenum>

    You are prompted for the Admin PIN. The HSM generates the keypair and exports the self-signed POC to the PTK client certificate store (Owner_POC.crt).

    If you run ctident list all again, you will see that there is a certificate in the POC-Pending state. To establish this cert as the ProtectServer Owner Certificate, you must use the POK to sign a ProtectServer Identity Certificate (PIC).

  3. Generate the certifying HSM CA's PIK/PIC as follows:

    • If you will use the HSM CA in production with other HSMs available to this PTK client: Specify the HSM CA's device or serial number (sn:<serialnum>), and a comma-separated list of other available HSMs you wish to authenticate (or all to authenticate all available HSMs). This list should include the HSM CA (which authenticates its own PIK/PIC).

    ctident gen-key <CA_devicenum> <CA_devicenum,devicenum,devicenum... | all>

    You are prompted for the Admin PIN of the certifying HSM CA, and for each HSM being authenticated in turn. Each HSM creates a PIK/PIC, and the PIC is signed by the HSM CA's POK. If any of the HSMs already have a PIK/PIC set, you are prompted to confirm that you wish to overwrite the existing PIK/PIC. The new PIC is exported to the PTK client certificate store.

    To certify more ProtectServer 3 HSMs as they are added later, see Authenticating ProtectServer 3 HSMs with an HSM CA in production.

    If you have other PTK clients that will access these HSMs using Secure messaging, see Importing the ProtectServer certificate chain to a new PTK client.

  4. If you are keeping this HSM CA offline and separate from the other HSMs it will authenticate: Specify the HSM CA's device or serial number (sn:<serialnum>) twice, to indicate that the HSM CA should create a PIK/PIC for itself and use the POK to sign the PIC.

    ctident gen-key <CA_devicenum> <CA_devicenum>

    To certify ProtectServer 3 HSMs in production using the offline HSM CA, see Authenticating ProtectServer 3 HSMs with an offline HSM CA.

Authenticating ProtectServer 3 HSMs with an HSM CA in production

You can use this procedure to generate a PIK on a new HSM and have its PIC signed by your ProtectServer 3 HSM CA. Use this procedure when your HSM CA is used in production and it is available to the same PTK client as the new HSM. This procedure is completed by the Administrator using the ctident tool.

Prerequisites

  • The ProtectServer 3 HSM CA and the new HSM must be available to the same PTK client machine.

  • Ensure that you have initialized the Admin token on the new HSM(s) (see Initial configuration). You will need to provide the Admin PIN for each HSM being authenticated.

  • Ensure that you have synchronized the HSM clock(s) with the correct time on your PTK client (see Adjusting the HSM clock).

  • If you want to customize the location of the PTK client certificate store, edit the path in the ET_PTKC_GENERAL_CERT_STORE variable. For more information about editing the path in this variable, refer to General ProtectToolkit-C configuration items.

To create a PIK and sign its PIC with a ProtectServer 3 HSM CA in production

  1. Generate the HSM's PIK/PIC by specifying the HSM CA's device or serial number (sn:<serialnum>), and the device or serial number of the HSM you wish to authenticate (or a comma-separated list of multiple HSMs, or all to certify all available HSMs).

    ctident gen-key <CA_devicenum> <devicenum,devicenum,devicenum,... | all>

    You are prompted for the Admin PIN of the HSM CA, and for each HSM being authenticated in turn. If any of the HSMs already have a PIK/PIC set, you are prompted to confirm that you wish to overwrite the existing PIK/PIC. The new PIC is exported to the PTK client certificate store.

  2. If you have other PTK clients that will access this HSM using Secure messaging, see Importing the ProtectServer certificate chain to a new PTK client.

Authenticating ProtectServer 3 HSMs with an offline HSM CA

You can use this procedure to generate a PIK on a ProtectServer 3 HSM and have its PIC signed by your ProtectServer 3 HSM CA. Use this procedure if your HSM CA is kept offline and separate from the rest of the HSMs it will authenticate. This procedure is completed by the Administrator using the ctident and ctcert tools.

Note

If you choose to use a POK/POC to authenticate HSMs for trust management, all HSMs that will trust each other must have their PIC signed by the same POK. Thales recommends using only one POK/POC, unless you wish to keep separate deployments of HSMs that explicitly cannot establish trust relationships between them.

A PTK client can hold only one POC at a time, so if you wish to maintain separate deployments, each deployment requires its own separate clients.

Prerequisites

  • The ProtectServer 3 HSM you wish to use as the HSM CA must be installed and available to PTK client machine A, with a valid POK/POC (see Establishing a ProtectServer 3 HSM as the HSM certificate authority).

  • The ProtectServer 3 HSM(s) you will authenticate must be installed and available to PTK client machine B.

  • Ensure that you have initialized the Admin token on the ProtectServer 3 HSM(s) you wish to authenticate (see Initial configuration). You will need to provide the Admin PIN for each HSM being authenticated.

  • You must have a secure method of transferring the certificates between client A and client B.

  • Ensure that you have synchronized the HSM clock(s) with the correct time on your PTK client (see Adjusting the HSM clock).

  • If you want to customize the location of the PTK client certificate store, edit the path in the ET_PTKC_GENERAL_CERT_STORE variable. For more information about editing the path in this variable, refer to General ProtectToolkit-C configuration items.

To create a PIK and sign its PIC with an offline ProtectServer 3 HSM CA

  1. (Optional) List the ProtectServer 3 HSMs available to PTK client B.

    ctident list all

  2. On PTK client B, generate a PIK and Certificate Signing Request (CSR) for the HSM(s) you wish to authenticate by specifying its device or serial number (sn:<serialnum>), a comma-separated list of multiple HSMs, or all to generate CSRs for all available HSMs.

    ctident gen-csr <devicenum,devicenum,devicenum,... | all>

    The CSR is automatically stored on the client in the location reported by the ctident utility, named for the HSM serial number (HSM_<serialnum>.csr).

    The PIK is held in a PIK-Pending state until the HSM's PIC is signed by the HSM CA.

  3. Securely transfer the CSR file(s) from PTK client B to PTK client A.

  4. On PTK client A, import the CSR to the Admin token on the ProtectServer 3 HSM CA by specifying the CSR filename, a label for the certificate, and the Admin slot.

    ctcert i -f<CSR_filename> -l<label> -s<Admin_slot>

  5. (Optional) Display the keys available on the HSM Admin token.

    ctkmu l -s<Admin_slot>

  6. Sign the CSR with the POK by specifying them by label as reported by cktmu.

    ctcert c -l<CSR_label> -c<POK_label> -s<Admin_slot>

    The PIC is automatically given the same label as the CSR.

  7. Export the newly-signed PIC to PTK client A.

    ctcert x -l<PIC_label> -f<filename> -s<Admin_slot>

    When prompted, choose the signed PIC to export -- it will have the same label as the old CSR.

    Repeat steps 5 to 7 for each additional CSR you want to authenticate with the HSM CA.

  8. Export the HSM CA's POC to PTK client A (the default label is POC).

    ctcert x -l<POC_label> -f<filename> -s<Admin_slot>

  9. Securely transfer the POC and the newly-signed PIC(s) from PTK client A to PTK client B.

  10. On PTK client B, import the POC to the HSM(s) being authenticated by specifying its device or serial number (sn:<serialnum>), a comma-separated list of multiple HSMs, or all to import the POC to all available HSMs.

    ctident store-poc -p<POC_filename> <devicenum,devicenum,devicenum,... | all>

  11. Import each HSM's newly-signed PIC by specifying its device or serial number (sn:<serialnum>).

    ctident store-pic -p<PIC_filename> <devicenum>

Creating a PIK and self-signed PIC on a ProtectServer 3 HSM

If you decide not to use a ProtectServer 3 HSM as an HSM Certificate Authority, you must create self-signed PIK/PIC keypairs on each of your ProtectServer 3 HSMs. These PICs are exchanged between different ProtectServer 3 HSMs to establish trust for Secure messaging or Token replication. This procedure is completed by the Administrator for each individual HSM using the ctident tool. If you are the Administrator for multiple HSMs, you can use this procedure to generate PIK/PIC keypairs for all of them at once.

Prerequisites

  • Ensure that you have initialized the ProtectServer Admin token(s) (see Initial configuration).

  • Ensure that you have synchronized the HSM clock(s) with the correct time on your PTK client (see Adjusting the HSM clock).

  • If you want to customize the location of the PTK client certificate store, edit the path in the ET_PTKC_GENERAL_CERT_STORE variable. For more information about editing the path in this variable, refer to General ProtectToolkit-C configuration items.

To create a PIK and self-signed PIC

  1. (Optional) List the ProtectServer 3 HSMs available to the PTK client.

    ctident list all

  2. Generate the PIK/PIC by specifying the HSM device or serial number (sn:<serialnum>), a comma-separated list of multiple HSMs, or all to generate PIK/PICs for all available HSMs.

    ctident gen-selfsigned <devicenum,devicenum,devicenum,... | all>

    You are prompted for the Admin PIN for each HSM in turn. If any of the HSMs already have a PIK/PIC set, you are prompted to confirm that you wish to overwrite the existing PIK/PIC. The new PIC is exported to the PTK client certificate store.

  3. If you have other PTK clients that will access this HSM using Secure Messaging, see Importing the ProtectServer Certificate Chain to a New PTK Client.

Importing the ProtectServer certificate chain to a new PTK client

If you are setting up a new PTK client that will access a ProtectServer 3 HSM using Secure Messaging, you must first import the HSM's certificate chain to the client's certificate store.

Prerequisites

  • Ensure that the HSM has a valid PIC.

  • The PTK client software must be installed and the HSMs must be accessible via the client tools (see ProtectToolkit 7 software installation).

  • If you want to customize the location of the PTK client certificate store, edit the path in the ET_PTKC_GENERAL_CERT_STORE variable. For more information about editing the path in this variable, refer to General ProtectToolkit-C configuration items.

To import the ProtectServer certificate chain to a new PTK client

  1. [Optional] List the ProtectServer 3 HSMs available to the PTK client.

    ctident list all

  2. Use the following command to fetch the certificate chain from any ProtectServer 3 HSM by specifying the device or serial number (sn:<serialnum>) as reported by ctident list all. You can perform this action even if SMS is already enabled on the HSM:

    ctident fetch-certs <devicenum,devicenum,devicenum,... | all>

Establishing trust between ProtectServer 3 HSMs

This procedure allows you to establish trust relationships between ProtectServer 3 HSMs by exchanging their PICs. Refer to Trust management for an overview of different trust schemes and their benefits. A trust relationship is required for Token replication. The Administrator for both HSMs must complete this procedure using the ctident tool. The example below will create the trust relationship depicted in the following diagram:

HSM Trust Relationship

Prerequisites

To establish trust between ProtectServer 3 HSMs

  1. (Optional) List the ProtectServer 3 HSMs available to the PTK client.

    ctident list all

  2. Use the ctident tool to share an HSM's PIC with other HSMs that will trust it, by specifying their device or serial number (sn:<serialnum>) as described below. Thales recommends specifying HSMs by their serial number to ensure that correct relationships are established. If one HSM goes offline during the process, the device number assigned to other HSMs may change. Specify first the source HSMs (the trusted HSMs) and then the destination HSMs (those that will trust the former) in a comma-separated list (or all to specify every HSM available to the client -- ctident trust all all makes every available HSM trust every other available HSM).

    ctident trust sn: <trusted_HSM(s)> sn:<trusting_HSM(s)>

    # ctident trust sn:1197 sn:1111,sn:1310

# ctident trust sn:1111,sn:1310 sn:1197

Removing trust between ProtectServer 3 HSMs

You can use the following procedure to remove a trust relationship between HSMs that you no longer wish to use Token replication. This procedure is completed by the Administrator using the ctident tool.

To remove trust between ProtectServer 3 HSMs

  1. (Optional )List the ProtectServer 3 HSMs available to the PTK client.

    ctident list all

  2. Use the ctident tool tool to remove an HSM's PIC from the HSM that will no longer trust it, by specifying their device or serial numbers (sn:<serialnum>) as described below. Thales recommends specifying HSMs by their serial number to ensure that correct relationships are established. If one HSM goes offline during the process, the device number assigned to other HSMs may change. Specify first the trusting HSM and then the HSM(s) to remove in a comma-separated list (or all to remove all trust from this HSM -- ctident remove all all removes all trust relationships between HSMs visible to the PTK client.

    ctident remove sn: <trusting_HSM(s)> sn:<HSM(s)_being_removed_from_trust>

    # ctident remove sn:1197 sn:1111,sn:1310

On this page